home *** CD-ROM | disk | FTP | other *** search
-
- ~4Dgifts/toolbox/documents/dwarf README
-
-
- `!' indicates new or updated as of version 4.2
-
-
- For further reference, also see toolbox/FAQs/SGIfaqs/Dwarf-faq,
- ! and the new libdwarf src (for IRIX 6) subtree in src/swtools/libdwarf.
-
-
- DWARF is a binary debugging-information-format. It defines, in detail,
- a way for compilers to tell debuggers about source programs.
-
- DWARF1 is the DWARF produced by USL's SVR4 compilers and used by their
- debuggers. It is no more capable than the MIPS mdebug symbol table
- and is less dense than mdebug. We will not use DWARF1.
-
- SGI will be using DWARF 2. It is capable of recording much more
- detailed information than DWARF 1 and is far more compact (debugging
- information in DWARF2 format takes much less space on disk than
- debugging information in DWARF1 format).
-
-
-
- ! dwarf.v2.ps: "DWARF Debugging Information Format," 108 pages
-
- FOREWARD
-
- This document specifies the second generation of symbolc debugging
- information based on the DWARF format that has been developed by
- the UNIX International Programming Languages Special Interest Group
- (SIG). It is being circulated for industry review. The first
- version of the DWARF specification was published by UNIX
- International in January, 1992. The current version adds
- significant new functionality, but its main thrust is to acheive
- a much denser encoding the DWARF information. Because of the new
- encoding, DWARF version 2 is not binary compatible with DWARF
- version 1.
-
- As this point, the SIG believes that this document sufficiently
- supports the debugging needs of C, C++, FORTRAN 77, Fortran90,
- Modula2, and Pascal, and we have released it for public comment.
- We will accept comments on this document until September 30, 1994.
- Comments may be directed via email to the SIG mailing list
- (plsig@ui.org). If you are unable to send email, paper mail, FAX,
- or machine readable copy on UNIX, MS-DOS, or Macintosh compatible
- media can be sent to UNIX International at the address listed
- below, and wil be forwarded to the SIG.
-
- UNIX International
- Waterview Corporate Center
- 20 Waterview Boulevard
- Parsippany, NJ 07054
- Phone: +1 201-263-8400
- Fax: +1 201-263-8401
-
- NOTE: Table of Contents is on page 105
- List of Figures is on page 107
- 108 pages
-
-
- ! index.v2.ps: 3-page index
-
-
- ! libdwarf2.1.ps: ABSTRACT: This document describes an interface to a
- library of functions to access DWARF debugging
- information entries and DWARF line number information.
- It does not make recommendations as to how the functions
- described in this document should be implemented nor
- does it suggest possible optimizations.
-
- The document is oriented to reading DWARF version 2.
- There are certain sections which are SGI-specific (those
- are clearly indentified in the document). We intend to
- propose this to the PLSIG committee as the basis for a
- standard libdwarf interface.
-
- The proposals made in this document are subject to
- change.
-
- 47 pages
- NOTE: CONTENTS is on page 45
- LIST OF FIGURES is on page 46
- ABSTRACT is on page 47
-
- ! libdwarf2p.1.ps: "A Producer Library Interface to DWARF"
- 17 pages
- NOTE: CONTENTS is on page 16
-
-
-
-
- ______________________________________________________________________________
-
- from the toolbox/FAQs/SGIfaqs/dwarf-faq file:
-
-
-
- 4) An Overview of Dwarf Information Content
-
- The documents mentioned in section 3 are long on details and short
- on overview. Lets try to put this all in to a total picture.
-
- To represent Debugging Information in an a.out we need several quite
- different categories of information spread across various
- ELF object file sections.
-
- A. Information about code and data variables.
- DWARF information is a tree of Debugging Information Entries (DIEs).
- Each tree entry (Die) has a TAG which identifies what type
- of entry it is and Attributes which give the details.
- DIEs at the global level in a compilation unit are tied together
- with Sibling Pointers.
- Siblings are equal-level DIEs.
- Children, on the other hand, are *owned* DIEs.
- Lets adopt the following symbols for DIE relationships:
- Sibling pointer ->
-
- Child pointer |
- v
-
- Here is a representation of the DIEs for t.c where types are
- left out to keep things simple (they don't change this, they
- are just more DIEs to clutter things up):
- t.c:
- int foo(int i, int j) { return 3;}
- int goo;
-
-
- Compilation_Unit
- |
- v
- function "foo" -> global variable "goo "
- |
- v
- parameter "i" -> parameter "j"
-
- This goes in the .debug_info section with a tiny amount
- of supporting data in .debug_abbrev
- B. Information about the mapping from code addresses to source
- A separate section holds a very compact mapping from
- code addresses to source lines (and columns).
- This is in the .debug_line section.
- C. Information about C Macros
- If desired, all C Macro #defines and #undef-s and
- #includes are recorded, with
- the mapping back to the source files.
- This is in the .debug_macinfo section.
- D. Information about unwinding stack frames
- This is specially recorded in a section of its own: a seperate
- small string of bytes per function/procedure.
- This is in the .debug_frame section.
-
- Other .debug_* sections are for supporting data or for fast access to
- global names, types, and statics.
-
-